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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



rd , 



The present document is part of a TS-family covering the 3 Generation Partnership Project; Technical Specification 
Group Services and System Aspects; Telecommunication management; as identified below: 

32.391: "Delta Synchronization Integration Reference Point (IRP); Requirements". 

32.392: "Delta Synchronization Integration Reference Point (IRP); Information Service (IS)". 

32.396: "Delta Synchronization Integration Reference Point (IRP); Solution Set (SS) definitions". 

The Itf-N interface is built up by a number of IRPs and a related Name Convention, which realise the functional 
capabilities over this interface. The basic structure of the IRPs is defined in 3GPP TS 32.101 [1] and 
3GPPTS 32.102 [2]. 

IRPManagers (typically Network Management Systems) and IRP Agents (typically EMs or NEs) synchronize their data 
concerning alarms or configuration data. In certain scenarios this synchronization is lost or not done. This IRP provides 
functionality to significantly reduces the amount of data which needs to be transferred in order to re-establish 
synchronization. 
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Scope 



The purpose of Delta Synchronization IRP is to define an interface through which an IRPManager can request only 
those data which changed (i.e. changed, were created or deleted) from a synchronization point onwards. 

The present document is the Information Service of Delta Synchronization IRP. It defines, for the purpose of Delta 
Synchronization, the information observable and controlled by management system's client and it also specifies the 
semantics of the interactions used to carry this information. 



References 



The following documents contain provisions that, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document 
(including a GSM document), a non-specific reference implicitly refers to the latest version of that document in 
the same Release as the present document. 

[I] 3GPP TS 32.101: "Telecommunication management; Principles and high level requirements". 

[2] 3GPP TS 32.102: "Telecommunication management; Architecture". 

[3] 3GPP TS 32.302: "Telecommunication management; Configuration Management (CM); 

Notification Integration Reference Point (IRP): Information Service (IS)". 

[4] 3GPP TS 32.391: "Telecommunication management; Delta Synchronization Integration Reference 

Point (IRP): Requirements". 

[5] 3GPP TS 32.150: "Telecommunication management; Integration Reference Point (IRP) Concept 

and definitions". 

[6] 3GPP TS 32.622: "Telecommunication management; Configuration Management (CM); Generic 

network resources Integration Reference Point (IRP): Network Resource Model (NRM)". 

[7] 3GPP TS 32.312: "Telecommunication management; Generic Integration Reference Point (IRP) 

management; Information Service (IS)". 

[8] 3GPP TS 32.602: "Telecommunication management; Configuration Management (CM); Basic CM 

Integration Reference Point (IRP): Information Service (IS)". 

[9] 3GPP TS 32.662: "Telecommunication management; Configuration Management (CM); Kernel 

CM; Information Service (IS)". 

[10] 3GPP TS 32.342: "Telecommunication management; File Transfer (FT); Integration Reference 

Point (IRP): Information Service (IS)". 

[II] 3GPP TS 32.1 1 1-2: "Telecommunication management; Fault Management; Part 2: Alarm 
Integration Reference Point (IRP): Information Service (IS)". 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TS 32.101 [1], 3GPP TS 32.102 [2] 
and 3GPP TS 32.391 [4] apply. 

synchPoint Creation Policy: The IRP Agent may create synchronizationPoint in different policies. These policies are 
called synchPoint creation policies. There are two synchPoint Creation policies: 

AgentScheduledPolicy: A new synchronizationPoint is created by the IRP Agent on the IRP Agent's internal decision, 
that decision is not related to any IRPManager's operations. In this mode, after successful delta synchronization, the 
IRP Agent does not create a new synchronizationPoint. 

ManagerRequestPolicy: The new synchronizationPoint is requested by the IRPManager. The exact time for this 
synchronizationPoint is determined by the IRP Agent. 

The IRP Agent that supports either AgentScheduledPolicy or ManagerRequestPolicy to create a new 
synchronizationPoint can claim compliance to this specification. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

CM Configuration Management 

EM Element Manager 

IOC Information Object Class 

IRP Integration Reference Point 

IS Information Service (see 3GPP TS 32. 101 [1]) 

Itf-N Interface N 

NE Network Element 



£75/ 



3GPP TS 32.392 version 10.0.0 Release 10 



ETSI TS 132 392 VI 0.0.0 (2011-04) 



4 System overview 

4.1 System context 

The general definition of the System Context for the present IRP is found in 3GPP TS 32.150 [5], clause 4.7. 
In addition, the set of related IRP(s) relevant to the present IRP is shown in figures 4.1-1 and 4.1-2. 
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Figure 4.1.1 : System Context A 
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Figure 4.1.2 : System Context B 
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5 Information Object Classes 

5.1 Information entities imported and local labels 



Label reference 


Local label 


3GPP TS 32.622 [6], information object class, Top 


Top 


3GPP TS 32.622 [6], information object class, IRPAgent 


IRPAgent 


3GPP TS 32.622 [6], information object class, GenericiRP 


GenericiRP 


3GPP TS 32.312 [7], information object class, ManagedGenericIRP 


ManagedGenericIRP 


3GPP TS 32.302 [3], information object class, Notif icationiRP 


Notif icationiRP 
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5.2 Class Diagram 

5.2.1 Attributes and relationsinips 

This clause introduces the set of Information Object Classes (lOCs) that encapsulate information within the 
IRPAgent. The intent is to identify the information required for the delta synchronization IRP Agent implementation 
of its operations and notification emission. This clause provides the overview of all support object classes in UML. 
Subsequent clauses provide more detailed specification of various aspects of these support object classes. 



«InformationObjectClass» 
ManagedGenericIRP 

(from TS 32.312) 



TV 



«InformationObjectClass» 
Deltas ynchronizationIRP 



Figure 5.2.1 : Information Object Class (IOC) UML Diagram 



5.2.2 Inlneritance 



«InformationObj ectClass» 

Top 

(from TS 32.622) 



7^ 



«InformationObj ectClass» 

GenericIRP 

(from TS 32.622) 



'A 



«InformationObj ectClass» 
ManagedGenericIRP 

(from TS 32.312) 



TV 



«InformationObj ectClass» 
Deltas ynchronizationIRP 



Figure 5.2.2: Information Object Class (IOC) Inheritance UML Diagram 
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5.3 Information Object Class (IOC) definitions 
5.3.1 DeltaSynchronizationIRP 

5.3.1.1 Definition 

DeltaSynchronizationIRP is the representation of the deha synchronization capabilities specified by the 
present document. This IOC inherits from ManagedGenericIRP IOC specified in 3GPP TS 32.312 [7]. 

5.4 Information relationship definitions 

none 

5.5 Information attribute definition 

none 
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6 Interface definition 



6.1 Class diagram 



«InformationObj ectClass» 
DeltaSynchronizationIRP 



«may realize» 



«realizes» 



«may realize» 



«Interface» 
DeltaSynchOfCMData 

triggerDeltaSynchOfCMDat 



«Interface» 
Deltas ynchGenericParts 

manageDeltaSynchronization 

«opt» 
get AvailableDeltaS ynchPoints 

«opt» 
notifyNewDeltaSynchPoint 

«opt» 
notifyStatusOfDelta 
Synchronization 



«Interface» 
DeltaSynchOfAlarmData 

triggerDeltaS ynchOf Alarms 



Figure 6.1 : Class diagram 



6.2 Generic rules 



Rule 1: each operation with at least one input parameter supports a pre-condition valid_input_parameter which 

indicates that all input parameters shall be valid with regards to their information type. Additionally, each 
such operation supports an exception operation_failed_invalid_input_parameter which is raised when pre- 
condition valid_input_parameter is false. The exception has the same entry and exit state. 

Rule 2: each operation with at least one optional input parameter supports a set of pre-conditions 

supported_optional_input_parameter_xxx where "xxx" is the name of the optional input parameter and 
the pre-condition indicates that the operation supports the named optional input parameter. Additionally, 
each such operation supports an exception operation_failed_unsupported_optional_input_parameter_xxx 
which is raised when (a) the pre-condition supported_optional_input_parameter_xxx is false and (b) the 
named optional input parameter is carrying information. The exception has the same entry and exit state. 

Rule 3: each operation shall support a generic exception operation_failed_internal_problem which is raised when 
an internal problem occurs and that the operation cannot be completed. The exception has the same entry 
and exit state. 
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6.3 deltaSynchGenericParts Interface (M) 
6.3.1 Operation manageDeltaSynchronization (M) 



6.3.1.1 



Definition 



This operation allows an IRPManager to activate or deactivate the delta synchronization functionality for CMData 
or/and AlarmData. A change of at least one activation status triggers the sending of 

notifyStatusOfDeltaSynchronization. 

As default settings the delta synchronization functionality for both alarms and CM data is deactivated. 

6.3.1 .2 Input parameters 



Parameter Name 


Qualifier 


Information 
type 


Comment 


managerRef erence 


M 


See 32.302 [3] 


See 3GPP TS 32.302 [3] 


manageDeltaSynchForAlarmData 


CM 


ENUM( 

Activate, 
Deactivate 

) 


Constraint: 
manageDeltaSynchForCMData is absent. 


manageDeltaSynchForCMData 


CM 


ENUM( 

Activate, 
Deactivate 

) 


Constraint: 
manageDeltaSynchForAlarmData is absent 



6.3.1.3 



Output parameters 



Parameter 
Name 


Qualifier 


Matching 
Information 


Comment 


status 


M 


ENUM( 

Success, 

Failure 

) 


If tlie functionality is already activated/disactivated the output value is Success and 

no notifyStatusOfDeltaSynchronization is triggered. 
Failure reasons are: 

DeltaSynchNotSupportedForCMData, 
DeltaSynchNotSupportedForAlarmData and Other unspecified reasons. 



6.3.1.4 Pre-condition 

deltaSynchSupported 



Assertion Name 


Definition 


deltaSynchSupported 


The IRPAgent supports the delta synchronization functionality. 



6.3.1.5 Post-condition 

requestGranted 



Assertion Name 



Definition 



requestGranted 



The delta synchronization functionality is activated or deactivated according to the input parameters 

manageDeltaSyncForAlarmData and manageDeltaSynchForCMData. 
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6.3.1.6 Exceptions 



Name 


Properties 


operation_f ailed 


Condition: the pre-condition is false or the post-condition is false. 
Returned Information: The output parameter status. 
Exit state: Entry state. 
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6.3.2 Operation getAvailableDeltaSynchPoints (O) 



6.3.2.1 



Definition 



This operation allows an IRPManager to request information about the synchronization points for which the 
IRPManager can request delta synch data from the IRP Agent. 



6.3.2.2 



Input parameters 



Parameter Name 


Qualifier 


Information 
type 


Comment 


managerRef erence 





See 32.302 [3] 


See 3GPP TS 32.302 [3] 


SynchPoint sForCMDataRequested 


CM 


Boolean 


Constraint: 

SynchPoint SForAlarmDataReques ted is 
absent 


SynchPoint sForAlarmDataReques ted 


CM 


Boolean 


Constraint: 
synchPointsForCMDataRequested is absent 



Remark: The constraints allow the simultaneous presence of both synchPointsForCMDataRequested and 

synchPointsForAlarmDataRequested in the input. 



6.3.2.3 



Output parameters 



Parameter Name 


Qualifier 


Matching 
Information 


Comment 


SynchPoint Li stForAlarms 


CM 


LIST of 
SynchPoint 


Constraint: 

synchPointsForAlarmDataRequested was present in the 

input and had value TRUE. 

If synchPointsForAlarmDataRequested was not present, 
then this parameter shall not be present in the output. 

If delta synchronization for alarm data is deactivated, then this list 
shall be empty. 

The content of this list is valid, if the status is either Success or 
Del taSynchNot Support edForCMData or 
DeltaSynchForCMDataDeactivated 


SynchPoint Li stForCMDat a 


CM 


LIST of 
SynchPoint 


Constraint: 

SynchPointsForCMDataRequested was present in the input 

and had value TRUE. 

If SynchPointsForCMDataRequested was not present, then 
this parameter shall not be present in the output. 

If delta synchronization for CM data is deactivated, then this list 
shall be empty. 

The content of this list is valid, if the status is either Success or 
Del taSynchNot Support edForAlarmDat a or 
DeltaSynchForAlarmDataDeactivated 


status 


M 


ENUM( 

Success, 
Failure 

) 


If both delta synchronization for CM data and alarm data are 
deactivated, then status == DeltaSynchNotActive. 
Failure reasons are: 

Del taSynchNot Support edForCMData, 
Del taSynchNot Support edForAlarmDat a, 
DeltaSynchNotActive , 
DeltaSynchForCMDataDeactivated, 
DeltaSynchForAlarmDataDeactivated, 
Failure and other unspecified reasons. 
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6.3.2.4 Pre-condition 

deltaSynchronizationSupported 



Assertion Name 


Definition 


deltaSynchronizationSupported 


The delta synchronization functionality is supported. 



6.3.2.5 



Post-condition 



synchPoint Li stsRe turned 



Assertion Name 


Definition 


synchPoint Li stsReturned 


The available information is returned. 



6.3.2.6 



Exceptions 



Name 


Properties 


operation failed 


Condition: the pre-condition is false or the post-condition is false. 
Returned Information: The output parameter status. 
Exit state: Entry state. 
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6.3.3 Notification notifyNewDeltaSynchPoint (O) 



6.3.3.1 



Definition 



If the IRPAgent has successfully performed the creation of a new delta synchronization point, then this notification is 
sent out to all subscribed IRPManagers. If an implementation chooses that the new delta synchronization point shall 
only be valid for specific IRPManagers, it can send the notification only to those. 

This notification is triggered by any of the following: 

1. An operation triggerDeltaSynchOf CMData or triggerDeltaSynchOf AlarmData returns the 
status == Success and a new synchronization point is created). 

2. An IRP Agent's internal decision to create a new synchronization point and that decision is not related to any 
IRPManager's operations. 

The use of the synchronizationPoint delivered in this notification may result in different views of the managed instances 
by IRPManager and IRPAgent, in some scenarios. To avoid such pitfall, it is recommended that the IRPManager should 
do the following: 

1 . Establish the first synchronizationPoint using the full synchronization; and 

2. Use the operations in the future to a) maintain/track the list of synchronization points and b) to update its view 
of the CM managed instances and FM alarm information. 



6.3.3.2 



Input Parameters 



Parameter Name 


Qualifier 


Matching Information 


Comment 


newSynchPoint 


M, Y 


Generalizedlime 




request edSynchPoint 


M, N 


Generalizedlime 


This parameter allows an IRPManager to 

relate this notification to its 

triggerDeltaSynchOf CM/AlarmDat a 

request. 

In case the newSynchPoint was triggered 

by an IPRAgent's internal decision this 

parameter carries the value 0. 


del taSynchPoint Type 


M, Y 


ENUM( 

deltaSynchPointForAlarm, 
del taSynchPoint ForCMDat a 

) 




triggeredByAgentOrManager 


M, Y 


ENUM( 

iRPAgent , 
iRPManager 

) 


This parameter indicates whether the 
creation of the new synchronization point 
was triggered by an IPRAgent's internal 
decision or by the request of an 
IRPIVIanager for an operation 
triggerDeltaSynchOf CMDat a/alarms 


agentOrManagerRef erence 


M, Y 


String 


In case the new synch point was triggered 

by an IPRAgent's internal decision this 

parameter carries the reference of the 

IRPAgent, else the managerRef erence 

of the IRPManager which requested the 

operation 

triggerDeltaSynchOf CMData/alarms 
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Triggering Event 



6.3.3.3.1 From-state 

newSynchPointSuccessfullyCreated 



6.3.3.3.2 To-state 

irpManagersInf ormedAboutNewSynchPoint 
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Assertion Name 


Definition 


newSynchPointSuccessfullyCreated 


The IRPAgent has successfully performed the 
to creation of a new delta synchronization 
point, see clause 6.3.3.1. 



Assertion Name 


Definition 


irpManagersInf OrmedAboutNewSynchPoint 


The involved IRPManagers are informed about the new synchPoint. 
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6.3.4 Notification notifyStatusOfDeltaSyncliClianged (O) 



6.3.4.1 



Definition 



If the IRP Agent has successfully performed a manageDeltaSynchronization request and the status of delta 
synchronization for alarm data and/or for CM data has changed, then this notification is sent out. 

6.3.4.2 Input Parameters 



Parameter Name 


Qualifier 


Information type 


Comment 


managerRef erence 


M, Y 


See 32.302 [3] 


See 3GPP TS 32.302 [3] 


deltaSynchStatusForCMData 


M, Y 


ENUM( 

Activated, 
Deactivated 

) 




deltaSynchStatusForAlarmData 


M, Y 


ENUM( 

Activated, 
Deactivated 

) 





6.3.4.3 



Triggering Event 



6.3.4.3.1 From-state 

statusOfDeltaSynchWasChanged 



Assertion Name 


Definition 


StatusOfDeltaSynchWasChanged 


The IRPAgent has successfully performed a 
manageDeltaSynchronization request and at least one delta 
synchronization status changed. 



6.3.4.3.2 



To-state 



irpManagersInformedAboutTheStatusChange 



Assertion Name 


Definition 


irpManagersInf ormedAboutTheStatusChange 


The IRPIVIanagers are informed about the new delta synch status. 
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6.4 deltaSynchOf CMData Interface (O) 

6.4.1 Operation triggerDeltaSynchOfCMData (M) 
6.4.1.1 Definition 

This operation allows an IRPManager to request information about CMData which has changed since the specified 
synchronization point. The information returned may be filtered/restricted by the input parameters 

baseMOInstance and scope. 

If the operation is successful, then a new delta synchronization point for CMData is created, if the IRP Agent supports 
the ManagerRequestPolicy. 

If the IRP Agent only supports AgentScheduledPolicy, the latest synchronizationPoint is returned to the IRPManager as 
the newSynchPoint. 

The Synchronization points created are not related to baseMOInstance and scope used in operations. In other 
words, it is not possible to establish synchronization points for just a subset of the managed objects. 

For obtaining an initial synchronization point (e.g. in the case that the IRPManager does not have any valid 
configuration management information), IRPManager shall use this operation triggerDeltaSyncOf CMdata as 
follows to obtain the first synch point: 

the input parameter synchPoint is present and the value is set to 0. 

The IRP Agent responds with newSynchPoint a Synchronization point that the IRPManager can use as the input 
parameter synchPoint for future triggerDeltaSynchOfCMData requests. 

A Solution Set may choose to split this operation in several operations (e.g. operations to get "iterator" which fulfil the 
criteria and other operations to retrieve the detailed information of the files from the "iterator"). 

If in the output of this operation a reference to a file is identified, then the availability of the file shall be announced by a 
notifyFileReady notification (see [10]). 
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6.4.1.2 



Input parameters 



Parameter Name 


Qualifier 


Information type 


Comment 


managerRef erence 





See TS 32.302 [3] 


See 3GPP TS 32.302 [3] 


cmDataRequested 


M 


ENUM( 

DNsOnly, 
CompleteDataSet) 


If cmDataRequested==DNsOnly: Only the DNs of MOIs are 
delivered in the output, not the complete data set of the MOIs. 
If dataRequested==CompleteDataSet: The complete data 
set of MOIs (including the attributes and their values) are 
delivered in the output. 


baseMOInstance 





See TS 32.602 [8] 


See 3GPP TS 32.602 [8] 

This parameter is used to reduce the amount of data which is 

returned in deltaLists. 

Remark: The parameter objectlnstance of a 

notifyCIVIsynchronizationRecommended notification could be used 

as input here. 

If this parameter is absent, then the all MOIs are used. 


scope 





See TS 32.662 [9] 


See 3GPP TS 32.662 [9] 

This parameter can be used to reduce the amount of delta data 

which is returned in deltaLists. 

If baseMOInstance is present, then this parameter shall be 

present. If the parameter baseMOInstance is absent, then this 

parameter must be absent. 

If the IRP-Agent has no complete view of the requested scope, 

then it shall deliver all known delta data within the scope. 


synchPoint 


M 


GeneralizedTime 


The IRPManager asks for data which changed since this 
synchPoint. 
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6.4.1.3 



Output parameters 



Parameter 


Qualifier 


Matching Information 




Name 






,.^.... -..,« -^ .. » _. .. >.^. .^,. * . l;ll 


deltaLists 


CM 


STRUCT < 


The second STRUCT contains the data which changed between 






STRUCT < 


StartTime and endTime. 






startTime, 








endTime 


In case the value of status equals "Success" an empty list 






> 


indicates that the information at startTime and the information 






STRUCT < 


at endTime are identical.. 






listOf Createdlnstances 


Constraint: 






listOf Changedlnstances 


If status is different from Success OR input 
synchPoint==o, then this parameter shall be absent, else it 






listOfDeletedlnstances 








> 


shall be present. 






> 


Remark: Square brackets indicate optional parts in the data 






listOf. ..Instances LIST: 


structure. If the IRPManager requested DNsOnly, then the 






either 


attribute list shall be absent. 






LIST of STRUCT 








<MOInstance [, 
attributeList] > 
or 


If the values of a managed object, identified by its DN, at 
StartTime and at endTime are identical, then 






a list of file 


either nothing about it shall be reported in the 






reference 


listOf Changedlnstances 
or 

the value at endTime (or startTime) reported, provided 

that the value has changed between startTime and 

endTime 
If the managed object does not exist at startTime and 
endTime, then nothing about it shall be reported, if the IRPAgent 
can fulfil the delta synchronization request exactly, i.e. for exactly 
the request synchPoint. 

If an instance is deleted and a new instance is created with the 
same identifier as the deleted instance, then both the creation 
and the deletion shall be reported. 

If several file references are used, then IRPManager shall 
process them in sequence, i.e. first file first, second file as 
second, etc. . 


newSynchPoint 


CM 


GeneralizedTime 


Constraint: 

baseMOinstance and scope were absent in the input 

This parameters defines a new synchronization point which can 

be used as input to this operation in the future. 


Status 


M 


ENUM( 


Failure reasons are: 






Success, 


SynchrPointTooLongAgo , 






Failure 


TooManyChangesFullSynchronizationRecommended, 






) 


SynchPointUnknown, 

DeltaSynchNotSupportedForCMData, 

DeltaSynchForCMDataDeactivated, 

and other unspecified reasons. 

In case the deltaSynchronizationlRP's data has been rebuilt, e.g. 

after a "crash", SynchPointUnknown is usod. 
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6.4.1.4 Pre-condition 

baseMOInstanceExists AND deltaSynchronizationOf CMDatalsActive 



Assertion Name 


Definition 


baseMOInstanceExists 


baseMOInstance does exist (Assertion == TRUE if no 
baseMOInstance was specified). 


deltaSynchronizationOf CMDatalsActive 


Tine delta synchronization functionality for CIVIData is active 



6.4.1.5 



Post-condition 



deltaListsRe turned 



Assertion Name 


Definition 


deltaListsReturned 


The required information is returned. 



6.4.1.6 



Exceptions 



Name 


Properties 


operation_f ailed 


Condition: the pre-condition is false or the post-condition is false. 
Returned Information: The output parameter status. 
Exit state: Entry state. 
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6.5 deltaSynchOfAlarmData Interface (O) 

6.5.1 Operation triggerDeltaSynchOf Alarms (M) 
6.5.1.1 Definition 

This operation allows an IRPManager to request information about all alarm information which has changed since the 
specified synchronization point. The information returned may be filtered/restricted by the input parameters 
baseMOInstance and scope. 

If the operation is successful, then a new delta synchronization point for alarm data is created, if the IRP Agent supports 
the ManagerRequestPolicy. 

If the IRP Agent only supports AgentScheduledPolicy, the latest synchronizationPoint is returned to the IRPManager as 
the newSynchPoint. 

The synchronization points created are not related to baseMOInstance and scope used in operations. In other 
words, it is is not possible to establish synchronization points for just a subset of the managed objects 

For obtaining an initial synchronization point (e.g. in the case that the IRPManager does not have any valid alarm 
information), IRPManager shall use this operation triggerDeltaSynchOf Alarms as follows to obtain the first 
synch point: 

the input parameter synchPoint is present and the value is set to 0. 

The IRP Agent responds with newSynchPoint a synchronization point that the IRPManager can use as input 
parameter synchPoint for future triggerDeltaSynchOf Alarms requests. 

A Solution Set may choose to split this operation in several operations (e.g. operations to get "iterator" which fulfil the 
criteria and other operations to retrieve the detailed information of the files from the "iterator"). 

If in the output of this operation a reference to a file is identified, then the availability of the file shall be announced by a 
notifyFileReady notification (see [10]). 
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6.5.1.2 



Input parameters 



Parameter Name 


Qualifier 


Information type 


Comment 


managerRef erence 





See 3GPP TS 32.302 [3] 


See 3GPP TS 32.302 [3] 


alarmDataRequested 


M 


ENUM( 

AlarmldsOnly, 
CompleteAlarmInf ormation 

) 


If dataRequested== AlarmldsOnly: Only the 

alarmed values are delivered in the output, not the 

complete alarm information. 

If dataRequested==CompleteDataSet: The 

complete alarm information are delivered in the 

output. 


baseMOInstance 





See 3GPP TS 32.602 [8] 


See 3PP TS 32.602 [8] 

This parameter is used to reduce the amount of data 

which is returned in deltaLists. 

Remark: The parameter objectlnstance of a 

notifyAlarmListRebuilt notification could be used as 

input here. 

If this parameter is absent, then the all MOIs visible 

via Itf-N is used. 


scope 





See 3PP TS 32.662 [9] 


See 3PP TS 32.662 [9] 

This parameter can be used to reduce the amount of 
delta data which is returned in deltaLists. 
If the parameter baseMOinstance is present, then 
this parameter shall be present. If the parameter 
baseMOInstance is absent, then this parameter 
must be absent. 

If the IRP-Agent has no complete view of the 
requested scope, then it shall deliver all known delta 
data within the scope. 


synchPoint 


M 


GeneralizedTime 


The IRPManager asks for data which changed since 
this synchPoint. 
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6.5.1.3 



Output parameters 



Parameter 


Qualifier 


Matching Information 




Name 






.... .. ',.^, - ^ - 1' Ulll 


deltaLists 


CM 


STRUCT < 


These second STRUCT contains the data which changed between 






STRUCT < 


StartTime and endTime. 






startTime, 








endTime 


In case the value of status equals "Success" an empty list 






> 


indicates that the information at startTime and the information at 






STRUCT < 


endTime are identical. 






listOfNewAlarms , 








listOf ChangedAlarms, 


Constraint: 






listOfDeletedAlarms 


If value of status is different from Success OR input 






> 


synchPoint==o, then this parameter shall be absent, else it shall 






> 


be present. 






listOf..Alarms LIST: 








either 


Remark: Square brackets indicate optional parts in the data 






LIST of STRUCT 


structure. If the IRPManager requested AlarmidsOnly, then the 






<alarm [, 


parameter list shall be absent. 






parameterList] > 








or 

a filename 


If an alarm information, identified by its alarmld, at startTime and 
at endTime is identical, then either 

nothing about it shall be reported 
or 

the alarm information at endTime (or startTime) reported. 














provided that the alarm information has changed 








between startTime and endTime. 








If an alarm is raised and cleared again and acknowledged between 








StartTime and endTime, then these changes should not be 








reported, if the IRPAgent can fulfil the delta synchronization request 








exactly 








If an alarm is deleted and a new alarm occurs with the same 








parameter values as the deleted alarm, then both the occurrence 








and the deletion shall be reported. 








If several file references are used, then IRPManager shall process 








them in sequence, i.e. first file first, second file as second, etc. . 


newSynchPoint 


CM 


GeneralizedTime 


Constraint: 

baseMOinstance and scope were absent in the input 

This parameters defines a new synchronization point which can be 

used as input to this operation in the future. 


Status 


M 


ENUM( 


Failure reasons are: 






Success, 


SynchPointTooLongAgo , 






Failure 


TooManyChangesFullSynchronizationRecommended, 






) 


SynchPointUnknown, 

DeltaSynchNotSupportedForAlarmData, 

DeltaSynchForAlarmsNotActive, 

and other unspecified reasons. 

In case the deltaSynchronizationlRP's data has been rebuilt, e.g. 
after a "crash", synchPointunknown is used. 



6.5.1.4 Pre-condition 

baseMOInstanceExists AND deltaSynchOf AlarmDatalsActive 



Assertion Name 


Definition 


baseMOInstanceExists 


baseMOinstance does exist. (Assertion == TRUE if no 
baseMOinstance was specified). 


deltaSynchOf AlarmDatalsActive 


The delta synchronization functionality for alarms is active 
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6.5.1.5 



Post-condition 



deltaListsRe turned 



Assertion Name 


Definition 


deltaListsReturned 


The required file information is returned. 



6.5.1.6 Exceptions 



Name 


Properties 


operation_f ailed 


Condition: the pre-condition is false or the post-condition is false. 
Returned Information: The output parameter status. 
Exit state: Entry state. 
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7 Operation Modes 



Several modes of operation for delta Synchronization are possible. An implementation supporting at least one of them 
can claim compliance to this specification. 

For each mode of operation, the DeltaSynchronizationIRP needs to support CMData delta Synchronization or 
AlarmData delta Synchronization or both. 

Further details to the operation modes and examples how to use them are supplied in Annex A. 

7.1 Delta Synchronization IVIode DSIVII 

In this operation mode DSMl the DeltaSynchronizationIRP only needs to support the following operations and 
notifications: 

• triggerDeltaSynchOf CMData 

• triggerDeltaSyncOf AlarmData 

• optionally notifyNewDeltaSynchPoint 

In this mode of operation, the DeltaSynchronizationIRP may ignore the use of managerRef erence input 
parameter. 

7.2 Delta Synchronization IVIode DSM2 

In this operation mode DSM2, the use of managerRef erence is mandatory. 

Otherwise, in this mode of operation the DeltaSynchronizationIRP supports all operations and notifications and 
their parameters which are qualified as M(andatory) in this specification. 

7.3 Delta Synchronization Mode DSM3 

In this mode of operation DSM3, the DeltaSynchronizationIRP supports all operations and notifications and 
their parameters as defined in this specification. 
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Annex A (informative): 

Modes of operation for delta synchronization 

The following two modes of operations are possible. IRP Agent can claim compliance if only one is supported. 

A.1 Operation IVIode DSIVII 

Example for this mode of operation: 

Suppose tO, tl, t2, t3, t4 and so on are the synchPoints. 

Suppose an IRPManager invokes a trigger with synchPoint==0 (requesting full sync data) at tx where t2<tx<t3, the 
DeltaSynchronizationIRP will return all data up to t2 and return the t2 as the newSynchPoint. 

This IRPManager should use t2 as the synchPoint for future trigger. 

Suppose this IRPManager invokes a trigger with synchPoint==t2 at ty where t4<ty<t5, the 
DeltaSynchronizationIRP will return delta data between t2 and t4. 

This mode of operation is suitable for IRPManagers that do not require synchronization of data at all time. 

In this mode of operation, the DeltaSynchronizationIRP may pre-assign the synch points based on a fixed 
frequency. In the example above, the durations between sync points tO, tl, t2 and so on would be identical. This 
frequency can be a system configuration time parameter and made known to IRPManager via non-standard means. 

A.2 Operation IVIode DSM2 

This mode of operation supports to handle requests of individual IRPManagers individually. 

This mode of operation is suitable for an IRPManager that require synchronization of data at any time, i.e. not requiring 
synchronization of data at some predefined fixed intervals. 

A.3 Operation Mode DSM3 

This mode of operation provides all options of delta Synchronization. 
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Annex B (informative): 
Change history 



Change history 


Date 


TSG# 


TSG Doc. 


CR 


R 


Subject/Comment 


Cat 


Old 


New 


Dec 2006 


SA 34 


SP-060735 


-- 


-- 


Submitted to SA#34 for Information 


-- 


1.0.0 




Mar 2007 


SA 35 


SP-070053 


-- 


-- 


Submitted to SA#35 for Approval 


-- 


2.0.0 


7.0.0 


Jun 2007 


SA 36 


SP-070276 


0001 


-- 


Correct thie information type of the input parameter 


F 


7.0.0 


7.1.0 


Jun 2007 


SA 36 


SP-070276 


0002 


-- 


Add missing mode of operations 


F 


7.0.0 


7.1.0 


Sep 2007 


SA 37 


SP-070612 


0003 


-- 


Add missing type definition 


F 


7.1.0 


7.2.0 


Sep 2007 


SA_37 


SP-070675 


0004 


1 


Correct thie parameter definitions of operation 
getAvailableDeltaSynchPoints 


F 


7.1.0 


7.2.0 


Dec 2008 


SA 42 


-- 


-- 


-- 


Upgrade to Release 8 


-- 


7.0.0 


8.0.0 


Dec 2009 


- 


- 


- 


- 


Update to Rel-9 version 


- 


8.0.0 


9.0.0 


2011-03 










Update to Rel-10 version (MCC) 




9.0.0 


10.0.0 
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